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REMARKS 

By this amendment, claims 1-45 are pending, in which no claim is canceled, withdrawn, 
currently amended, or newly presented. No new matter is introduced. 

The Office Action mailed June 28, 2006 objected to claims 7 and 14 as being dependent 
upon a rejected base claim and rejected claims 1-45 based on the judicially created doctrine of 
obviousness-type double patenting. Further, claims 1, 2, 4, 8, 9, 11, and 15 were rejected under 
35 U.S.C. § 102(e) as anticipated by Hammarstrom et al. (US 6,044,142), claims 16-45 were 
rejected under 35 U.S.C. § 102(e) as anticipated by Havens (US 5,881,144), and claims 3, 5, 6, 
10, 12, and 13 were rejected under 35 U.S.C. § 103(a) as obvious based on Hammarstrom et al. 
in view oiPullen et al. (US 6,198,813). 

First, Applicants acknowledge and appreciate the indication that claims 7 and 14 would 
be allowable if rewritten in independent form. 

In response to the obviousness-type double patenting rejection, Applicants submit, 
herewith, a terminal disclaimer in compliance with 37 C.F.R. § 1.321, thereby rendering the 
rejection moot. 

Regarding the remaining rejections of record, Applicants respectfully traverse on the 
merits for the reasons provided below. 

Independent claims 1, 8, and 15 recite, "creating a customer application file using a 
customer-specified sequence of said service-independent building blocks in a server of said 
telecommunications network, wherein a set of customer specific data is defined for use as 
inputs into said set of service-independent building blocks." The Office Action, on page 3, 
applies Hammarstrom et al. to supposedly teach the above features, citing FIG.l, as well as, col. 
2, lines 10-16, and col. 3, line 47 - col. 4, line 10, and asserting that "a user creates a customer 
specific application using the service-independent building blocks on information provided by 
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the customer." Applicants respectfully disagree with the proposed reading of Hammarstrom et 

al, as the applied reference does not teach or suggest that a "customer-specified sequence" or 

"customer specific data . . . inputs" are related to the disclosed intelligent network (IN) services. 

At best, Hammarstrom et al. merely discloses that network operators, not customers, design and 

create their own, not customer-specified, IN services, wherein service logic and service data are 

combined into service building block (SIB) sequences and therefore, are not used as inputs nor 

are customer specific. 

Specifically, Hammarstrom et al discloses, on col. 1, line 64 - col. 2, line 16, the 

following (Emphasis Added): 

A significant advantage of intelligent networks is that the service control 
architecture is independent of the underlying communications network. Each IN 
service is typically composed of several service features or basic, reusable 
components called service independent building blocks (SIBs). Service 
independent building blocks provide network operators with the ability to 
design their own advanced services as service "scripts" simply by properly 
selecting and sequencing basic service script modules. A service script combines 
service logic and service data in a particular sequence of SIBs designed and 
tested to provide a particular service. During call processing and rendering of a 
service, the service script corresponding to the service is "interpreted" or executed 
to provide the requested service. Each new service is defined, specified, 
developed, and tested in a special service creation environment linked to a 
service management system (SMS) and then simply downloaded to the service 
control point. Service script software need only be implemented in the SCP and 
not in every switch within the network. 

At best, Hammarstrom et al reveals that network operators, not customers, are provided 

with a host of reusable service independent building blocks (STBs) for designing their own 

intelligent network (IN) services. This lack of disclosure is consistent with the objectives of 

Hammarstrom etal, which discloses (col. 3, lines 11-32) the following: 

It is an object of the invention to provide cooperation between live operators and 
automated IN-based services. 

It is an object of the invention to provide a mechanism by which service feature 
requests and responses are communicated between the service logic of an IN- 
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based service and a human operator workstation. 

The present invention overcomes these problems and needs and achieves these 
and other objects by integrating automatic IN services with operator-assisted 
services on business, service, and technology levels. This integration broadens 
the service portfolio that a service provider offers to subscribers to include 
both automatic and manually assisted (i.e., operator-assisted) services. 
Moreover, the flexibility of IN, script-based service development may be 
advantageously deployed to develop services that involve both automatic and 
operator service feature elements. In other words, both automatic and operator 
service features may be freely combined into new service scripts. An example of 
such an integrated script might be a "fall back" service to a human operator in the 
automatic attendant (IN) service as described above. 

From this passage, the subscriber is involved only to the extent that such subscriber is 
provided with operator-assisted services. Only the network operator has control over how the 
script-based services are developed. 

Further, while network operators can combine service logic and service data in a 
particular SIB sequence, this falls short of being characterized as either "input" or as "customer 
specific." Moreover, even though new IN services are created in a special service creation 
environment linked to a service management system, neither the environment nor the service 
management system are disclosed as "servers" or as distinctly part of the actual 
"telecommunications network." 

As anticipation under 35 U.S.C. § 102(e) requires that each and every element of the 
claim, as set forth in the claim, be disclosed in a prior art reference, based on the foregoing, it is 
clear that Hammarstrom et al. fails to anticipate independent claims 1, 8, and 15. Accordingly, 
independent claims 1, 8, and 15, along with claims 2, 4, 9, and 11, depending correspondingly 
therefrom, are in condition for allowance. 

Furthermore, the addition of Pullen et al. fails to cure the deficiencies of Hammarstrom et 
al. The Office Action, on pages 7-8, relies on Pullen et al for a supposed teaching of "defining 
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rules under which the service independent building blocks operate and defining inputs and 

outputs for each set of service-independent building blocks" and "defining a set of customer 

specific data for use as inputs in the service-independent building blocks during execution , . , 

and storing the customer specific data in an advanced network database to create a customer 

specific data file." Consequently, a prima facie case of obviousness has not been established. 

Therefore, Applicants respectfully request withdrawal of the obviousness rejection, and urge the 

indication that dependent claims 3, 5, 6, 10, 12, and 13, be allowed at least for the reasons 

proffered above, as well as on their own merits. 

For instance, dependent claims 5 and 12 recite, "storing said set of customer specific data 

in an advanced network database of said server to create a customer specific data file." The 

Office Action, on page 8, cites col. 2, lines 44-63 of Pullen et al. to supposedly teach these 

features; however, the cited passage merely states the following: 

In FIG. 1, CIBB 10 has a logic start 12. All CIBBs 10 have one logical starting 
point and one or more logical end points. Logic start 12 is the initialization or 
starting point for each CIBB 10. It sets the initialization conditions for each CIBB 
such as what specific information to receive and what response to generate. A 
service support data 14 is provided as an input. Service support data 14 is the 
input data required for a particular service. It can be information such as calling 
line identity, the called party, or any other input required for a specific service. 
Also provided as an input is a call instance data input 16. Call instance data input 
16 is data inputs which are specific to a particular call, such as routing lists, the 
trunk group a call came in on or other inputs relating to a specific call. A call 
instance data output 18 is data outputs which are specific to a particular call, such 
as a route list. The call instance data output 18 from one CIBB 10 can be a call 
instance data input 16 for another CIBB 10. In this way, CIBBs 10 can be 
combined as a chain or group. The call instance data output 18 can also be the end 
result of a call processing service. 

Notably, the above passage only indicates the existence of initialization logic, as well as 
input and output parameters that are generally speaking, specific to a particular call, not 
specific to a customer who specifies a sequence of service-independent building blocks for 
providing advanced interactive voice response services. Further, those input and output data that 



18 



10/613,054 Patent 
are disclosed are merely revealed as being passed from one entity to another, not necessarily 
stored. If any storage does occur, it is storage related to the temporal use of the data within the 
CIBBs, and not associated in any way with a database. Thus, at no point does Pullen et al. 
disclose, or otherwise suggest, the possibility of "customer specific data," an "advanced network 
database of said server," or even "storing" a set of data, much less in the context of the claims, 
i.e., "to create a customer specific data file." 

Similarly, Havens also fails to anticipate the claimed invention, namely claims 16-45. 
For instance, independent claims 16 and 21 recite, receiving "a message associated with a call 
invoking the IVR service, the message specifying an application identifier corresponding to a 
customer application file providing a call plan" and retrieving "the customer application file 
based on the application identifier." Claims 27 and 32 recite, receiving "a request for a 
customer application file that specifies a call plan, the request including an application 
identifier corresponding to the customer application file." Independent claims 38 and 42 recite, 
generating "a customer application file that specifies a call plan" and assigning "an identifier 
to the generated customer application file." 

The Office Action, on pages 4-6, cites col. 1, lines 39-50, col. 2, lines 10-29, col. 3, lines 
44-59, and col. 4, line 50 - col. 5, line 15 within Havens to supposedly teach the above features. 
Applicants, however, respectfully disagree. In particular, Havens fails to disclose both a 
"customer application file that specifies a call plan" and an "application identifier" that 
corresponds to the customer application file. Instead, Havens utilizes subscription data, e.g., a 
time of day datum, which is associated with a particular subscriber to ascertain the identities of 
the related service script logics (SSLs) of a given intelligent network (IN) service. Further, only 
through simulation can the Havens system determine a particular call plan. 
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Specifically, Havens utilizes a Service Script Logic (SSL) interpreter to analyze 
subscription data to ascertain the identity of the appropriate intelligent network (IN) service and 
the associated sequence of SSLs for executing that IN service, (col. 2, lines 14-17; col. 4, lines 
15-29; col. 4, line 62 - col. 5, line 2). For example, one type of subscription data that can be 
analyzed is a "time of day" datum, (col. 5, lines 3-9). When a "time of day" value is perceived 
by the interpreter, the module knows to associate a particular SIB, e.g., A-SIB, to that datum and 
further knows that the particular SIB can be associated with one or more SSL(s), (col. 5, lines 7- 
14). Through simulation of the identified SIB and/or SSL, the interpreter is able to determine 
which SIB or SSL application follows next, until all SIBs and/or SSLs are identified, (col. 5, 
lines 14-15). Thus, by link-listing or tracing the transition from one SSL to another, a full 
overview is determined, but at no point does Havens disclose that an application file specifying a 
call plan is utilized, much less an application identifier corresponding to the customer application 
file. 

Thus, it is clear that Havens fails to anticipate independent claims 16, 21, 27, 32, 38, and 
42 as each and every element of the claim, as set forth in the claim, is not taught by the reference. 
Accordingly, these independent claims along with claims 17-20, 22-26, 28-31, 33-37, 39-41, and 
43-45, depending correspondingly therefrom, are in condition for allowance. 

Therefore, the present application, as amended, overcomes the objections and rejections 
of record and is in condition for allowance. Favorable consideration is respectfully requested. If 
any unresolved issues remain, it is respectfully requested that the Examiner telephone the 
undersigned attorney at (703) 425-8508 so that such issues may be resolved as expeditiously as 
possible. 
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Respectfully Submitted, 
DITTHAVONG & MORI, P.C. 




Attorney/Agent for Applicant(s) 
Reg. No. 44658 

10507 Braddock Road 
Suite A 

Fairfax, VA 22032 
Tel. (703) 425-8508 
Fax. (703)425-8518 
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